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DEVELOPING  COMMUNICATIONS  TRAFFIC  PROFILES 
FOR  THE  MOBILE  USER  OBJECTIVE  SATELLITE  SYSTEM 

EXECUTIVE  SUMMARY 


The  Navy  Communications  Satellite  Program  Office  (PMW-146)  has  overall 
responsibility  for  executing  the  procurement  of  the  Navy’s  communications  satellites.  The 
Navy  plans  to  replace  the  current  Ultra  High  Frequency  Follow-On  (UFO)  satellite 
constellation  with  a  new  narrowband  system  called  the  Mobile  User  Objective  System 
(MUOS)  starting  in  2007.  In  order  to  acquire  a  system  that  has  adequate  but  not  excessive 
capacity,  the  MUOS  program  requires  knowledge  of  satellite  access  demand  to  a  level  of 
detail  sufficient  to  determine  scenario  based  capacity  requirements. 

To  detail  these  requirements,  a  Defense  Information  Systems  Agency  (DISA)  and 
support  contractor  team  developed  and  demonstrated  a  capability  to  generate  anticipated 
MUOS  satellite  access  demand  for  a  potential  user  subset.  This  subset  consisted  of  a 
Navy  Carrier  Battle  Group  (CVBG)  operating  in  a  Southwest  Asia  major  theater  war 
(MTW)  scenario.  By  using  the  Emerging  Requirements  Data  Base  (ERDB)  as  a  basis  for 
developing  Information  Exchange  Requirements  (IERs),  “traffic  profiles”  were 
developed  based  on  how  Warfighters  are  expected  to  use  MUOS  in  actual  combat 
situations. 

The  use  of  a  scenario,  the  development  IERs  from  the  ERDB,  the  utilization  of  an 
automated  traffic  generation  tool  tied  to  a  relational  data  base,  and  the  employment  of  a 
domain  expert  panel  were  all  essential  elements  of  the  effort.  Within  a  ten  hour  period, 
the  team  was  able  to  produce  20,472  records  (transmissions)  representative  of  a  Navy 
CVBG  employing  18  MUOS  networks  defined  in  the  ERDB. 

Analysis  of  the  results  revealed  some  networks  with  apparent  excess  throughput 
requirements  and  others  that  may  not  be  sufficient  to  meet  anticipated  Warfighter 
demands. 
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INTRODUCTION 


The  Navy  Communications  Satellite  Program  Office  (PMW-146)  of  the  Program 
Executive  Officer  for  Space,  Communications  and  Sensors  located  in  San  Diego, 
California  has  overall  responsibility  for  executing  the  procurement  of  the  Navy’s 
communications  satellites.  Today,  the  Navy’s  Ultra  High  Frequency  (UHF)  Follow-On 
(UFO)  constellation  provides  narrowband  satellite  communications  to  the  Warfighter. 

The  UFO  constellation,  initially  launched  in  1993,  is  projected  to  begin  to  reach  its  end  of 
life  in  the  early  2000s.  The  Navy  has  developed  an  acquisition  strategy  to  replace  the 
UFO  constellation  with  a  new  narrowband  system  starting  in  2007.  The  new  system, 
designated  the  Mobile  User  Objective  System  (MUOS),  will  provide  higher  data  rates  (up 
to  64  kilobits  per  second),  greater  capacity,  and  greater  mobility  -  it  will  be  accessible  by 
users  with  handheld  terminals. 

In  support  of  the  MUOS  program,  the  Defense  Information  Systems  Agency  (D2  and 
D8  Directorates)  with  the  assistance  of  its  support  contractor  team,  the  MITRE 
Corporation  and  SAIC,  developed  and  demonstrated  a  capability  to  generate  anticipated 
MUOS  demand  by  a  Navy  Carrier  Battle  Group  (CVBG)  operating  in  a  Southwest  Asia 
major  theater  war  (MTW)  scenario.  The  CVBG  consisted  of  nine  surface  ships,  three 
submarines,  20  F/A-18s,  eight  non-combatant  aircraft,  eight  helicopters,  cruise  missiles, 
an  Explosive  Ordnance  Disposal  Team,  and  two  Sea  Air  Land/Special  Operations  Forces 
(SEAL/SOF)  teams. 


ROLE  AND  LIMITATIONS  OF  THE  DOD  EMERGING  REQUIREMENTS 
DATA  BASE 

A  major  problem  that  occurs  whenever  satellite  architectures  and  designs  are 
formulated  is  to  adequately  determine  projected  capacity  and  utilization  requirements. 
Such  is  the  case  for  the  MUOS.  The  Department  of  Defense  (DoD),  recognizing  this 
problem,  initiated  an  effort  to  solicit  current  and  future  satellite  communication 
requirements  from  the  Services,  Agencies,  and  Unified  and  Specified  Commands.  The 
inputs  regarding  future  requirements  were  collected  and  entered  into  a  database  called  the 
Emerging  Requirements  Data  Base,  or  ERDB,  and  were  validated  by  the  Joint 
Requirements  Oversight  Council  (JROC).  The  data  base  is  maintained  by  the  Defense 
Information  Systems  Agency  (DISA)  and  the  requirements  collection  process  managed 
by  the  Joint  Staff  J8. 

The  ERDB  contains  information  such  as  required  data  rate,  type  operation  (half 
duplex,  full  duplex,  etc.),  service  availability  (e.g.,  on  call,  dedicated),  connectivity  (e.g., 
point-to-point,  netted),  protection,  mode  (voice,  video,  data),  priority,  and  duty  cycle  for 
each  uniquely  identified  link  or  net.  Units  (members)  participating  in  a  net  are  also 
identified  by  unit  type/name.  Network  participants  (usually  the  Service  network  control 
participant)  are  responsible  for  generating  ERDB  network  entries  and  submitting  them 
into  the  ERDB  approval  process.  Updates  occur  biannually. 
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Unfortunately,  the  ERDB  lacks  the  detailed  information  needed  to  determine 
expected  network  traffic  flow  that  must  be  considered  in  designing  a  satellite  system  to 
meet  user  demand  in  real  world  scenarios.  Specifically,  it  does  not  provide: 

•  The  communications  operational  tempo  that  varies  with  the  scenario 

•  The  information  exchanged  over  a  given  network  and  the  associated  volume 
of  traffic  that  must  be  accommodated  by  a  network  at  any  given  time  or  over  a 
period  of  time 

•  When,  and  how  often,  the  information  is  actually  injected  into  the  network 

•  Who  is  actually  sending  and  receiving  information  at  any  given  time 

This  type  of  information  is  referred  to  as  a  traffic  profile  and  the  process  of  obtaining 
such  information  is  called  traffic  profiling.  Obtaining  the  anticipated  traffic  profile  for 
the  MUOS  or  any  future  satellite  system  is  critical  to  ensuring  that  the  system  is  designed 
to  efficiently  accommodate  user  demand. 


DISA  APPROACH  TO  GENERATING  TRAFFIC  PROFILES  FOR 
THE  MUOS 

DISA  and  the  MITRE  Corporation  developed  a  process  for  creating  communication 
system  traffic  profiles  that  begins  with  the  ERDB.  Initially,  the  requirement  for 
generating  traffic  profiles  arose  from  a  desire  to  model  the  expected  performance  of  the 
Defense  Information  System  Networks  (DISN)  when  subjected  to  significant  loading 
from  a  major  contingency.  There  were  a  number  of  good  commercial  network  models 
available  but  traffic  loading  to  drive  the  models  was  lacking.  Generally,  the  models  were 
capable  of  generating  generic  traffic  profiles  using  various  algorithms  but  it  is  nearly 
impossible  to  correlate  these  profiles  to  real  world  contingencies  that  can  stress 
communication  networks  in  unpredictable  ways.  What  was  needed  was  a  way  of 
anticipating  and  documenting  traffic  that  was  scenario  dependent.  The  approach  to 
generating  this  traffic  includes  three  essential  elements  or  activities: 

•  Identifying  and  documenting  Information  Exchange  Requirements  (IERs)  for  a 
given  scenario  and  mapping  them  to  networks  in  the  ERDB 

•  Developing  and  utilizing  a  tool  for  generating  traffic  profiles  base  on  IERs 

•  Utilizing  a  panel  of  domain  experts  to  establish  communication  traffic  patterns  in 
an  operational  context 

Use  of  Information  Exchange  Requirements 

To  meet  this  need,  MITRE  developed  a  process  to  generate  scenario  dependent  traffic 
profiles  based  on  the  concept  of  Information  Exchange  Requirements  (IERs)  and 
Information  Exchange  Products  (IEPs).  An  IER  is  an  identified  requirement  for  two  or 
more  units  to  exchange  information  concerning  a  particular  subject.  IERs  are 
characterized  by  subject  matter,  a  sender,  receiver(s)  (may  be  multiple  recipients),  time  of 
transmission,  and  frequency  of  transmission  (how  often  a  transmission  occurs).  An  IEP  is 
the  actual  information  that  is  transmitted  and  is  characterized  by  subject  name  (e.g., 
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Situation  Report)  and  size  in  kilobits  for  data  or  a  call  duration  (minutes  or  seconds)  for 
voice. 

Key  to  our  approach  to  generating  MUOS  traffic  profiles  was  the  linkage  of 
IERs/IEPs  to  the  narrowband  satellite  networks  contained  in  the  ERDB.  By  examining 
the  narrowband  networks  in  the  ERDB,  it  was  possible  to  associate  an  IER  or  IERs  with  a 
network.  These  associations  were  documented  in  the  MITRE  developed  relational  data 
base  tool  called  the  Communications  Support  Planning  Tool  (CSPT).  The  CSPT  was 
used  to  record  each  request  for  satellite  access  based  on  a  postulated  scenario.  The  actual 
process  for  populating  the  CSPT  and  is  described  later. 

Use  of  The  Communications  Support  Planning  Tool 

The  CSPT  provides  a  mechanism  for  developing  communications  traffic  profiles  and 
analyzing  traffic  characteristics.  The  underlying  CSPT  relational  data  base  application  is 
an  IBM/LOTUS  product,  called  APPROACH  97®,  that  runs  on  a  Pentium  desktop 
computer  under  Windows  95/98  or  Windows  NT.  A  user  friendly  graphical  interface  to 
the  data  base  application  was  developed  to  permit  easy  entry  of  key  data  elements 
necessary  to  fully  characterize  a  transmission.  The  data  elements  that  must  be  entered  are: 
1)  the  information  sender  or  “Agent”,  2)  the  information  receiver  Agent(s),  3)  an 
information  exchange  product  (IEP),  4)  the  number  and  frequency  of  products  sent,  5)  the 
time  each  IEP  is  sent,  and  6)  the  net  over  which  the  product  is  transmitted.  Macro 
instructions  (macros)  were  written  that  automated  the  generation  of  multiple 
transmissions,  either  on  a  random  or  periodic  basis.  Each  transmission  was  automatically 
recorded  in  the  CSPT  constituting  a  data  base  “record”. 

After  the  data  was  entered,  the  CSPT  was  used  to  display  information  such  as  the 
number  of  transmissions  over  MUOS  over  a  24-hour  period;  the  total  number  of 
transmissions  by  network  or  unit;  the  number  of  transmissions  during  any  particular  hour 
by  network  or  unit;  and  the  hour  in  which  the  maximum  number  of  transmissions  occur. 
The  CSPT  provided  the  complete  traffic  profile  necessary  for  modeling  system 
performance. 

Use  of  Domain  Experts 

The  traffic  profiles  obtainable  with  the  CSPT  are  only  as  good  as  the  input  data.  To 
ensure  that  the  input  data  was  as  accurate  as  possible,  multiple  sources  and  methods  were 
used;  however,  the  primary  resource  used  to  reflect  how  individuals  nets  were  employed 
in  a  combat  situation  was  a  panel  of  experts  with  Service  experience.  For  the  MUOS 
demonstration  effort,  the  panel  of  domain  experts  (logistics,  combat  aircraft,  search  and 
rescue,  etc.)  were  drawn  from  individuals  within  the  DISA  and  contractor  team.  The 
panel  made  decisions  (sometimes  after  consultations  with  outside  experts)  on  what 
information  was  sent  over  what  net,  when  and  how  often,  to  whom,  and,  in  the  case  of 
voice  transmissions,  how  long  each  transmission  lasted.  All  this  information  was 
recorded  in  the  CSPT. 
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THE  MUOS  TRAFFIC  PROFILING  PROCESS 


The  four  step  process  followed  in  generating  MUOS  traffic  profiles  is  illustrated  in 
Figure  1. 


Develop 
Scenario 
and  lERs 


Extract 
ERDB  Data 
and  Map  to 
lERs 


Generate 
Traffic 
Using  CSPT 


Figure  1.  The  Four  Step  Process  in  Generating  MUOS  Traffic  Profiles 


Step  1  -  Develop  Scenario  and  lERs 

The  first  step  was  to  define  in  more  detail  the  Southwest  Asia  scenario  and  select  a 
particular  day  from  that  scenario  that  would  be  expected  to  place  a  heavy  demand  upon 
the  MUOS.  The  day  selected  was  Day  120  (24  hours)  when  forces  were  fully  engaged. 
There  were  two  highly  stressed  periods  during  the  day:  hours  0800  to  1100  and  1800  to 
2100.  The  combat  and  supporting  activities  that  were  expected  during  the  chosen  day 
were  fully  described  and  “time-stamped”  by  hour.  These  activities  were  further  examined 
to  identify  those  that  required  the  transfer  or  exchange  of  information  over  a  tactical 
narrowband  satellite  communications  system.  The  result  was  a  set  of  IERs. 

Step  2  -  Extract  ERDB  Data  and  Map  to  IERs 

The  second  step  was  to  associate  particular  IERs  with  MUOS  networks  and  the 
CVBG  units  likely  to  employ  the  narrowband  networks  listed  in  the  ERDB.  This  was 
done  by  taking  the  list  of  IERs  developed  in  Step  1  and  mapping  them  against  units 
and/or  networks  in  the  ERDB  that  were  likely  to  transmit  the  content  of  the  IER.  For 
example,  the  IER  “request  to  be  rescued”  coming  from  a  downed  pilot  with  a  survival 
radio  (SR)  would  be  sent  over  the  Combat  Survivor  Evader  Locator  (CSEL)  net.  The  SR 
transmission  consists  of  a  pre-set  number  and  sequence  of  bits  sent  periodically  that 
constituted  the  IEP.  Now  a  connection  has  been  established  between  the  scenario,  the 
IER/IEP,  the  projected  MUOS  network,  and  an  operational  unit  or  units. 
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Step  3  -  Generate  Traffic  Using  CSPT 

The  third  step  was  to  create  the  MUOS  traffic  profile  by  recording  in  the  CSPT  the 
basic  characteristics  of  each  transmission  during  the  selected  scenario  day  (24  hour 
period).  These  basic  characteristics  were  the  IER,  the  sending  unit,  the  receiving  unit  (or 
units  for  netted  operations),  the  network  utilized,  and  the  time  of  transmission.  For  data 
transmissions,  the  size  of  the  IER  (defined  as  an  Information  Exchange  Product  (IEP) 
measured  in  bytes)  was  defined,  and  for  voice  transmissions,  the  duration  of  each  call 
was  recorded  in  the  CSPT.  There  were  four  sources  for  this  data:  the  ERDB,  data 
collected  through  interviews  and  questionnaires,  data  collected  from  documents  and  data 
bases,  and  personnel  with  operational  communications  experience  -  our  domain  expert 
panel. 

CSPT  macros  were  used  to  create  multiple  transmissions  or  records.  For  example,  the 
“random  transmission”  macro  was  used  to  generate  multiple  transmissions  at  random 
times  (elapsed  time  in  seconds  from  0000)  once  a  start  time  and  number  of  desired 
transmissions  was  entered.  Similar  macros  were  used  to  create  transmissions  that  were 
sent  periodically  throughout  the  day. 

To  create  the  MUOS  traffic  profiles,  the  domain  expert  panel  met  for  about  10  hours 
over  a  period  of  two  days.  This  was  sufficient  to  create  approximately  20,000  voice  and 
data  transmission  records  originating  from  91  units  employing  18  different  networks. 
This  represents  approximately  one  tenth  of  the  total  ERDB  narrowband  satellite  nets. 

Step  4  -  Conduct  Analysis 

The  fourth  step  was  to  analyze  the  entered  data.  CSPT  permits  sorting  and  displaying 
data  in  several  formats.  It  was  used  to  show  information  such  as  the  number  of 
transmissions  over  MUOS  over  a  24-hour  period;  the  number  of  transmissions  by 
network  or  unit;  the  number  of  transmissions  during  any  particular  hour  by  network  or 
unit;  and  the  hour  in  which  the  maximum  number  of  transmissions  occur. 


ANALYSIS  RESULTS 

The  process  and  tools  described  above  enabled  the  DISA  team  to  developed  traffic 
profiles  showing  demand  for  satellite  access  (in  kilobits  for  data,  call  minutes  for  voice) 
for  each  of  the  18  networks  during  each  scenario  hour.  An  example  of  the  results  for  one 
network,  the  CSEL,  is  shown  in  Figure  2. 

The  scenario  used  to  generate  this  profile  involved  the  downing  and  rescue  of  four 
pilots  as  follows: 

1.  Four  F/A/18s  downed  between  0300  and  0430.  Pilot  1  downed  in  water  and 
transmits  609  bits  at  0330,  repeats  every  30  minutes.  Picked  up  in  two  hours  (0530  is  last 
transmission). 

2.  Pilot  2  downed  on  land.  Begins  to  transmit  at  0445  and  is  rescued  at  1045  (last 
transmission).  Transmission  size  and  frequency  same  as  pilot  1. 
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3.  Pilot  3  downed  on  land.  Begins  to  transmit  at  0315  and  is  rescued  at  0920. 
Transmission  size  and  frequency  same  as  pilot  1. 

4.  Pilot  4  downed  in  water.  Begins  to  transmit  at  0420  and  is  rescued  at  0630. 
Transmission  size  and  frequency  same  as  pilot  1. 


Figure  2.  Traffic  Profile  for  the  Combat  Survivor  Evader  Locator  Network 

This  figure  shows  that  the  CSEL  network  throughput  requirement  is  relatively  small. 
It  would  be  desirable  in  designing  a  satellite  system  to  provide  a  capability  to  access  this 
net  on  demand  but  not  tie  up  a  channel  all  the  time.  Figure  3  illustrates  the  effect  of 
dedicating  a  net  to  this  function  in  comparison  to  providing  an  on-demand  capability. 


1  3  5  7  9  11 

Time  Period  (Hour) 


Figure  3.  CSEL  On-Demand  Requirement  vs.  Dedicated  Net 
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SUMMARY 


The  DIS  A  team  developed  a  process  and  tool  that  was  used  successfully  to  generate 
MUOS  data  and  voice  traffic  profiles  for  a  typical  CVBG  in  a  combat  scenario.  The  use 
of  a  scenario,  the  development  IERs  from  the  ERDB,  the  utilization  of  an  automated 
traffic  generation  tool  tied  to  a  relational  data  base,  and  the  employment  of  a  domain 
expert  panel  were  all  essential  elements  in  the  success  of  the  effort.  The  team  was  able  to 
generate  a  MUOS  scenario  based  data  set  quickly  and  efficiently.  Within  a  ten  hour 
period,  the  expert  panel  was  able  to  produce  20,472  records  (transmissions) 
representative  of  a  CVBG  employing  18  MUOS  networks  identified  from  the  ERDB. 
Analysis  of  the  results  revealed  some  networks  with  apparent  excess  throughput  capacity 
(e.g.  CSEL)  and  other  networks  that  may  not  have  sufficient  capacity  to  meet  the  demand 
(e.g.  LAMPS). 


